Algebraic Subtyping

data types can be expressed neatly by treating their definition as transparent inside the module defining them, and as opaque outside it. Transparent definitions are easily implemented. In principle, they can be expanded in a preprocessing phase and ignored afterwards. In practice, this may cause an exponential increase in compile time as their definitions may be much larger than their names. This issue, however, is exactly the same as that faced by implementations of, say, Standard ML or Haskell. The addition of subtyping does not make this any more difficult, and the standard solutions (lazy expansion of type aliases) apply. So, we do not discuss this issue further. Opaque type definition cannot be preprocessed away. Instead, for each opaque type definition, we introduce a new component to the definition of the type lattice. For type definitions without parameters (like id above), this new component is simply 1, giving such definitions the same status as type variables or the type bool. Types with parameters are not much more difficult. To define a parameterised type ListPair[S, T], representing immutable lists whose elements are pairs of S and T, we simply add a component A×A to the definition of types. In general, the component corresponding to a type definition is a finite product of A and Aop, depending on whether the parameters are coor contra-variant. (In the example ListPair[S, T], both parameters are covariant). 9.1.1 Variance and mutability Most languages which support subtyping and user-defined types, from objectoriented languages like Java to functional ones like OCaml, support invariant parameters as well as coand contra-variant ones. Invariant parameters are neither conor contra-variant. If a type ty[T] is invariant, then ty[X] is a subtype of ty[Y] only when X and Y are equal. The classical examples of invariant parameters involve mutability. Suppose we have a type MList[T] of mutable lists whose elements are of type T, equipped with operations get and put to read and write elements of the list. The type of get applied such a list mentions T only in its return type, and is therefore covariant in T. However, the type of put applied to such a list mentions T only in its argument type, and is contravariant in T. The type MList[T] cannot therefore be said to be either coor contra-variant in T. Unlike coand contra-variant parameters, invariant parameters cannot be encoded using the small set of ingredients we have allowed ourselves. This is not a simple omission: many parts of the system described in this thesis assume that all fields of all type constructors are either coor contra-variant. For instance, the biunify algorithm produces a bisubstitution, acting differently on positive and negative occurrences of variables, while implicitly assuming that all occurrences of a variable are one or the other. Rather than admit defeat here, I argue that invariance is a poor way to describe the parameter of MList, which makes it gratuitously difficult to typecheck quite reasonable pieces of code. Consider the following piece of code in Java (where ArrayList plays the role of MList[T]): void disableAll(ArrayList comps) { for (Component c : comps) { c.setEnabled(false); } CHAPTER 9. EXTENSIONS 131